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TITLE: LANGUAGE FOR PERFORMING HIGH LEVEL ACTIONS USING 

HARDWARE REGISTERS 

TECHNICAL FIELD 
The present invention relates generally to utilizing a common hardware 
representation language, and more particularly to systems and methods that can utilize a 
common hardware register representation language to specify hardware functionality. 

BACKGROUND OF THE INVENTION 

In the computer hardware industry, there is a trend to develop devices with unique 
functionality. For example, hardware vendors seek to incorporate unique (e.g., 
proprietary) features to differentiate their device(s) from that of competitors. For 
example, even though register-based devices (e.g., debugger port, EMS port, system 
timer, interrupt controller, bus controller, . . .) employ hardware registers for 
communication and control, such devices can utilize the hardware registers in disparate 
manners depending on the vendor's design specification. Resources of register based 
devices include I/O, memory mapped or Configuration Registers. Register(s) can be 
physically located within the hardware or in another location, the size of a register(s) can 
vary (e.g., 16 bit, 32 bit, . . .), the function of a respective bit can vary, hardware 
functionality can differ depending on whether a bit is written to or read from, or how it is 
written to or read from, etc. 

Traditionally, utilization of these functionalities (e.g., unique to specific device, 
common within a class of devices, . . .) associated with register based hardware required 
developing a software driver that was hardware specific such that the driver correlated 
with semantics of the particular device. Numerous limitations result from the need for 
hardware specific device drivers. High costs are often associated with developing 
hardware specific device drivers, extensive software development time can be required to 
develop software capable of employing unique hardware functionalities, hardware 
development and utilization typically is slowed by unavailability of software capable of 
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taking advantage of unique features of the hardware initially when new hardware 
functionalities are created, and software development can be slowed because the software 
must conform with requirements of the hardware. 

Another shortcoming of conventional register based hardware is that hardware 
5 can be inaccessible prior to operating system kernel availability because a hardware 
specific device driver is required to interact with the device. Some operating system 
environments require access to the device prior to operating system boot up. Such 
limitation can render the hardware unusable for applications, such as, for example, a 
watchdog timer implemented to detect and respond to system failures prior to boot up and 

1 0 during initialization. 

There exists a need in the art for systems and methods that can facilitate operation 
of hardware devices during the entire lifetime of the operating system, including boot and 
shutdown time. Additionally, there exists a need for a simple, common platform to 
describe hardware functionality to reduce costs and time associated with developing 

15 hardware specific device drivers. Furthermore, systems and methods are lacking which 
are extensible to enable utilization of additional features in future hardware. Thus, there 
exists a need in the art for a system and/or method for utilizing a common language for 
performing high level actions. 



20 SUMMARY OF THE INVENTION 

The following is a summary of the invention in order to provide a basic 
understanding of various aspects of the invention. This summary is not intended to 
identify key/critical elements of the invention or to delineate the scope of the invention. 
Its sole purpose is to present some concepts of the invention in a simplified form as a 

25 prelude to the more detailed description that is presented later. 

The present invention provides for a system and method for utilizing a common 
hardware representation language. The common hardware register representation 
language can describe hardware functionality and can be utilized to execute hardware 
action(s). The hardware functionality can be specified in a manner that abstracts the 

30 device resources. Some operating system environments require access to hardware 

devices prior to operating system kernel availability. Typically, hardware functionality 
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can be implemented through specification of a finite set of hardware register operations. 
The present invention provides a framework for specifying hardware functionality and 
executing device action(s) through a common hardware register pseudo-language. The 
invention facilitates software development for a device class by providing a common 

5 abstraction of device specific instructions and resources needed to execute device 

functionality. The common hardware register pseudo-language utilizes primitives which 
are basic operations implemented on hardware registers. An instruction comprises the 
primitive and the resources upon which the primitive acts. Vendors can link together a 
set of instructions to perform an action. The set of instructions can be loaded with an 

1 0 Advanced Configuration and Power Interface (ACPI) table for implementation prior to 
boot or during initialization. 

Thus, the hardware register language of the subject invention describes a device's 
functionality {e.g., high level actions that can performed with a particular hardware 
device) using the action / instruction / primitive operation notation. The primitive 

1 5 operations can vary slightly with each respective implementation, but the language 

abstracts hardware at the instruction level. Therefore software can be written for device 
functionality which corresponds to actions that can be performed on a device. 

Hardware is typically register based such as, for example, a watchdog timer, 
debugger port, EMS port, interrupt controller, bus controller, etc. Functionality 

20 associated with the hardware is often unique for respective vendor specific hardware 
devices. The common hardware register pseudo-language provides a framework for 
vendor specification and execution of hardware functionality utilizing the series of 
instructions. The hardware register primitives can be, for example, reading or writing a 
set of bits on the hardware register. The hardware register primitives can be defined 

25 according to the common hardware register pseudo-language, and as noted above can be 
loaded with the ACPI table prior to boot or during initialization. Thus, the invention 
facilitates use of a common hardware driver to support unique functionality of the 
hardware device and the functionality can be utilized prior to operating system kernel 
availability. 

30 To the accomplishment of the foregoing and related ends, certain illustrative 

aspects of the invention are described herein in connection with the following description 
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and the annexed drawings. These aspects are indicative of various ways in which the 
invention may be practiced, all of which are intended to be covered by the present 
invention. Other advantages and novel features of the invention may become apparent 
from the following detailed description of the invention when considered in conjunction 
5 with the drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Figure la is an illustration of a system for specifying hardware functionality in 
accordance with an aspect of the present invention. 
10 Figure lb illustrates a couple of specific actions of the watchdog timer in 

accordance with the subject invention 

Figure 2 is an illustration of a system for specifying hardware functionality in 
accordance with an aspect of the present invention. 

Figure 3 is an illustration of a system for specifying hardware functionality in 
1 5 accordance with an aspect of the present invention. 

Figure 4 illustrates an instruction set for specifying hardware functionality in 
accordance with an aspect of the present invention. 

Figure 5 illustrates an instruction set for specifying hardware functionality in 
accordance with an aspect of the present invention. 
20 Figure 6 is a schematic block diagram of an exemplary system for specifying 

hardware functionality in accordance with an aspect of the present invention. 

Figure 7 is a schematic block diagram of an exemplary system for specifying 
hardware functionality in accordance with an aspect of the present invention. 

Figure 8 is a flow diagram of a method for specifying hardware functionality in 
25 accordance with an aspect of the present invention. 

Figure 9 is a flow diagram of a method for specifying hardware functionality in 
accordance with an aspect of the present invention. 

Figure 10 is a flow diagram of a method for specifying hardware functionality in 
accordance with an aspect of the present invention. 
30 Figure 1 1 is a schematic block diagram of an exemplary operating environment 

for a system configured in accordance with the present invention. 
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Figure 12 is a schematic block diagram of a sample-computing environment with 
which the present invention can interact. 

DETAILED DESCRIPTION OF THE INVENTION 

5 The present invention is now described with reference to the drawings, wherein 

like reference numerals are used to refer to like elements throughout. In the following 
description, for purposes of explanation, numerous specific details are set forth in order 
to provide a thorough understanding of the present invention. It may be evident, 
however, that the present invention may be practiced without these specific details. In 

10 other instances, well-known structures and devices are shown in block diagram form in 
order to facilitate describing the present invention. 

As used in this application, the terms "component" and "system" are intended to 
refer to a computer-related entity, either hardware, a combination of hardware and 
software, software, or software in execution. For example, a component may be, but is 

15 not limited to being, a process running on a processor, a processor, an object, an 

executable, a thread of execution, a program, and/or a computer. By way of illustration, 
both an application running on a server and the server can be a component. One or more 
components may reside within a process and/or thread of execution and a component 
may be localized on one computer and/or distributed between two or more computers. 

20 It is to be appreciated that, for purposes of the present invention, some or all of 

the functionality associated with modules, systems and/or components discussed herein 
can be achieved in any of a variety of ways (e.g., combination or individual 
implementations of active server pages (ASPs), common gateway interfaces (CGIs), 
application programming interfaces (API's), structured query language (SQL), 

25 component object model (COM), distributed COM (DCOM), system object model 

(SOM), distributed SOM (DSOM), ActiveX, common object request broker architecture 
(CORBA), database management systems (DBMSs), relational database management 
systems (RDBMSs), object-oriented database management system (ODBMSs), object- 
relational database management systems (ORDBMS), remote method invocation (RMI), 

30 C, C++, practical extraction and reporting language (PERL), applets, HTML, dynamic 
HTML, server side includes (SSIs), extensible markup language (XML), portable 
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document format (PDF), wireless markup language (WML), standard generalized markup 
language (SGML), handheld device markup language (HDML), graphics interchange 
format (GIF), joint photographic experts group (JPEG), binary large object (BLOB), 
other script or executable components). 

5 As used herein, the term "inference" refers generally to the process of reasoning 

about or inferring states of the system, environment, and/or user from a set of 
observations as captured via events and/or data. Inference can be employed to identify a 
specific context or action, or can generate a probability distribution over states, for 
example. The inference can be probabilistic - that is, the computation of a probability 

1 0 distribution over states of interest based on a consideration of data and events. Inference 
can also refer to techniques employed for composing higher-level events from a set of 
events and/or data. Such inference results in the construction of new events or actions 
from a set of observed events and/or stored event data, whether or not the events are 
correlated in close temporal proximity, and whether the events and data come from one 

1 5 or several event and data sources. 

Accordingly, the subject invention can employ various artificial intelligence based 
schemes for carrying out various aspects of the subject invention. Classification in 
accordance with the subject invention can employ a probabilistic and/or statistical-based 
analysis (e.g., factoring into the analysis utilities and costs) to prognose or infer an action 

20 that a user desires to be automatically performed. For example, a support vector 

machine (SVM) classifier can be employed. Other classification approaches include 
Bayesian networks, decision trees, and probabilistic classification models providing 
different patterns of independence can be employed. Classification as used herein also is 
inclusive of statistical regression that is utilized to develop models of priority. 

25 The present invention relates generally to systems and methods for utilizing a 

common hardware register representation language, and more specifically to utilizing a 
common hardware register representation language to specify hardware functionality. 
The systems and methods provide a framework for specifying hardware functionality 
through a common hardware register pseudo-language. The common hardware register 

30 pseudo-language provides a set of hardware register primitives. The invention facilitates 
vendor specification of hardware functionality by utilizing a subset of the hardware 
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register primitives. The subset of primitives (corresponding to the register based 
hardware devices) can be loaded with an Advanced Configuration and Power Interface 
(ACPI) table, and thus facilitate functionality prior to boot or during initialization. 

As noted supra, the hardware register language of the subject invention describes 
5 a device's functionality (e.g., high level actions that can performed with a particular 
hardware device) using the action / instruction / primitive operation notation. The 
primitive operations can vary slightly with each respective implementation, but the 
language abstracts hardware at the instruction level. Therefore software can be written 
for device functionality which corresponds to actions that can be performed on a device. 

10 Figure la illustrates a block diagram of a system 100 that specifies hardware 

functionality in accordance with an aspect of the present invention. The hardware 1 10 
can be a register-based device such as, for example, a watchdog timer, debugger port, 
EMS port, interrupt controller, bus controller, etc. In general, a register can be a 
collection of two or more D flip-flops with a common clock input. The number of D 

15 flip-flops determines the size of the register. The present invention contemplates 

hardware devices 1 10 created by various hardware vendors utilizing disparate registers 
1 12 varying in size, value, location, etc. For example, the size of the registers can be 16 
bits, 32 bits, 64 bits, etc. Therefore, the present invention contemplates utilization of a 
vendor's unique hardware 1 10 with disparate functionality, distinctive register design, 

20 etc. 

The system 100 additionally comprises a specification component 120 that 
specifies functionality of the hardware 1 10. The specification component 120 typically 
employs a language, such as a common hardware register pseudo-language 124. Such 
pseudo-language 124 can include a set of hardware register primitives 126 (e.g., reads, 

25 writes, masked reads, masked writes, . . .) which are defined for a device class and are a 
complete set of possible operations that can be performed upon a generic hardware 
register and thus, provides a common framework for specifying functionality. The 
pseudo-language 124 facilitates utilization of a common driver to support the hardware 
device 110 and thus, allows for an operating system to simply employ the hardware 

30 devices possessing unique functionalities. Execution of the hardware register primitive 
126 on a specific resource is called an instruction. 
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The specification component 120 can employ a subset series of instructions 
linked together to effectuate high level functionality {e.g., shut down computer, resetting 
a timer, . . .). An instruction comprises the primitive and resources to perform the 
primitive {e.g., register's location, register's size, value, a bitmask detailing the bits to 

5 read and/or write, an indicator identifying the action which the instruction is a part, . . .). 

The series of instructions can be referred to as an action. The present invention 
contemplates linking primitive operations on a set of registers, linking primitive 
operations on one register, etc. The series of linked instructions is defined for the 
hardware device 110 and effectuates operation of hardware functionalities, which can be 

10 unique to the device, common for a class of devices, etc. through a common platform. 

According to one particular aspect of the present invention, the specification component 
120 can utilize a resource table 130 that describes the linked instructions which 
comprises hardware register primitives and accompanying resources that constitute each 
hardware action. Included in the resource table 130, for example, can be a series of 

1 5 instructions with, for example, the primitive operation, the register's location, register's 
size, value, a bitmask detailing the bits to read and/or write, an indicator identifying the 
action which the instruction is a part, etc. Instructions for a single action can utilize the 
same indicator; however, in other aspects different indicators can be used. The resource 
table 130 can thus be transferred to the operating system, for example, with an Advanced 

20 Control and Power Interface (ACPI) table. 

The following discussion with respect to Figure lb, highlights one particular 
aspect of the hardware register language in connection with exemplary actions for a 
watchdog timer. A high level action may be achieved by a series of operations on a 
hardware device. The resources, and even operations can change from device to device 

25 but each can be abstracted as a series of instructions (as defined by the application) in 
accordance with the subject invention. 
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An instruction can include the following information: 
Instruction: 

Action Flag: The action flag indicates an action the particular instruction 
5 is a part of. If multiple instructions are supported per action one can consider an 
additional field indicating a position in the instruction series where a particular 
instruction takes place, in order to perform the specified action. In the watchdog timer, 
position is not required for this particular example, because in this particular 
implementation of the invention, the order of the instructions (in the resource table Fig, 
10 la) determine position of the instruction in the action's instruction series. 

Primitive Operation : The operation of the instruction. This can include, 
but is not limited to register reads, writes, masked reads, masked writes. In the 
implementation of the watchdog timer, eight primitive operations are defined, a read 
value, read countdown, write value and a write countdown each with a primitive 
1 5 operation that preserves the existing register value and one that does not preserve the 
existing register value. 

Instruction Arguments: 

Register: The register of the instruction. 

Bits in the register that pertain to the instruction : This can be described 
20 by a bit mask, indicating the bits within the register that pertain to the instruction. One 
example of this is the watchdog timer which defined the bit mask to have the bit set for 
each relevant bit of the register. (See watchdog excerpt below). 

Value: The value corresponding to the specified instruction. The meaning 
of the value will vary for each primitive operation and it's actual value will vary for each 
25 device. 



The following excerpt provides additional context for the hardware watchdog 
timer in accordance with the subject invention. 
Field Descriptions: 

30 Register Region is described as a Generic Address Structure. This 

structure describes the physical address of a register as well as the bit range that 
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corresponds to a desired region of the register. The bit range is defined as the smallest set 
of consecutive bits that contains every bit in the register that is associated with the 
Watchdog Instruction. For example, if bits [6:5] and bits [3:2] all correspond to a 
Watchdog Instruction, the bit range for that instruction would be [6:2]. Since a bit range 

5 could contain bits that do not pertain to a Watchdog Instruction (such as bit 4 in the 

example above), a bit mask is required to distinguish all bits in the region that do 
correspond to the instruction. A Mask field is defined to be this bit mask with a bit set to 
a * T for each bit in the bit range (defined by Register Region) corresponding to the 
Watchdog Instruction. Note that bit 0 of the bit mask corresponds to the lowest bit in the 

10 bit range. In the example used above, the mask would be 1 101 lb or Ox IB. 

Previously, the Generic Address Structure did not define size of the register it described. 
Reading or writing arbitrary bytes of a register can lead to indeterminate system behavior. 
As a result, the Watchdog Instruction Entry has a Register Size field to describe the size 
of the register. 

1 5 A Watchdog Instruction can be one of four instructions. The Value field of the 

Watchdog Instruction Entry has a specific meaning for each of the four instructions and 
each type of Watchdog Action. In general, the value field provides a mechanism to 
translate the value stored in the register to an internal format and vice versa. 

20 Watchdog Instructions 

WA TCHD O GINS TR U CTION_READ_ VALUE 

A Read Value Instruction reads Register Region and compares the resultant with 
Value. If the values are not equal, the instruction failed as did the parent Watchdog 
Action. This can be described in pseudo code as follows. 
25 X = Read(register) 

X = X » Bit Offset described in Register Region 
X = X & Mask 
If(X != Value) FAIL 
SUCCEED 

30 
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WA TCHDOGINSTRUCTIONREADCOUNTDOWN 

A Read Countdown Instruction reads Register Region. The resultant is a 
countdown value and should not be compared with Value. Value will be ignored. The 
countdown value is in count intervals. This can be described in pseudo code as follows. 
5 X = Read(register) 

X = X » Bit Offset described in Register Region 

X - X & Mask 

Return X 



1 0 WA TCHDOGJNSTRUCTION^ WRITE_ VALUE 

A Write Value Instruction writes Value to the Register Region. If 
WATCHDOG_PRESERVE_REGISTER is set in Instruction Flags, then the bits not 
corresponding to the Write Value Instruction are preserved. If the register is preserved, 
Write Value Instruction requires a read of the register. This can be described in pseudo 
1 5 code as follows. 

X = Value & Mask 

X = X « Bit Offset described in Register Region 
If (Preserve Register) 

Y = Read(register) 
20 Y = Y & -(Mask « Bit Offset) 

X = X | Y 
Write(X, Register) 



WA TCHDOG_INSTRUCTION_ WRITE ^COUNTDOWN 
A Write Countdown Instruction writes the internal Hardware Watchdog Timer 
Driver countdown value to the Register Region. The countdown value is the number of 
count intervals the driver has chosen to use for a countdown period. Value will be 
ignored. If WATCHDOG_PRESERVE_REGISTER is set in Instruction Flags, then the 
bits not corresponding to the Write Countdown Instruction are preserved. If the register 
is preserved, Write Value Instruction requires a read of the register. This can be 
described in pseudo code as follows. 
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X = countdown value 
X = X & Mask 

X = X « Bit Offset described in Register Region 
If (Preserve Register) 
5 Y = Read(register) 

Y = Y & -(Mask « Bit Offset) 

X = X|Y 
Write(X, Register) 



10 The above discussion is intended to provide context and highlight various novel 

aspects of the hardware register language of the subject invention, and it is to be 
appreciated that the subject invention is not limited to such these particular examples. 

Fig. la illustrates a couple of specific actions of the watchdog timer in accordance 
with the subject invention. The encoding of table 150 are instruction(s) to enable the 

15 watchdog timer. The instruction(s) indicate that primitive 0 X 82 (Preserving Write) 

should be employed to touch a register that is 32 bits wide located in PCI configuration 
space at Bus 0, Device 7, Function 3, and Offset 6c. The value used to enable the 
watchdog is 0x400 along with a mask of 0x400. This means that the instruction should 
only set the 1 1 bit in the register to Ox 1 and leave all other bits alone. 

20 The encoding of table 160 is the instruction(s) to disable the watchdog timer. The 

instruction indicates that primitive 0x82 (Preserving Write) should be employed to touch 
a register 32 bits wide located in PCI configuration space at Bus 0, Device 7, Function 3, 
Offset 6c. The value used to disable the watchdog is 0 along with a mask of 0x400. This 
means that the instruction should only clear the 1 1 bit in the register to 0x1 and leave all 

25 other bits alone. See Fig. 6 and discussion related thereto for another exemplary 

discussion relating to watchdog timers in accordance with the subject invention. Further 
high-level aspects of the subject invention will now be discussed in connection with the 
drawings. 

Figure 2 illustrates a system 200 for specifying hardware functionality in 
30 accordance with an aspect of the present invention. The system 200 comprises an 

interface component 210 that can communicate with software, firmware and/or hardware, 
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for example, to facilitate higher level functionality. The interface component 210 can 
interact with the hardware registers associated with such software, firmware and/or 
hardware. The hardware registers can vary in size, location, value, etc. to facilitate 
unique functionality. 

5 The interface component 210 typically utilizes a pseudo-language component 

220 and a linking component 230. The pseudo-language component 220 provides a set 
of hardware register primitives that are operable upon the associated hardware. The 
hardware register primitives include, for example, reads, writes, masked reads and 
masked writes of hardware register(s). The pseudo-language component 220 can be 

10 utilized as a common platform for describing unique hardware devices and executing 
device action(s). The pseudo-language component 220 can facilitate use of a common 
driver to leverage functionality of unique hardware devices - thus, the need for hardware 
specific drivers can be mitigated since a common framework can be utilized to describe 
primitive operations performed upon hardware registers for the particular device. 

1 5 The linking component 230 can be employed to link a series of instructions, 

which comprise hardware register primitives and resources utilized by the primitives that 
are described by the pseudo-language component 220. For example, the linking 
component 230 can join together a subset of hardware register primitives from the set of 
primitives described by the pseudo-language component 220 to perform a given device 

20 action The series of instructions describe a higher level hardware action such as, for 
example, rebooting the system, resetting a timer, etc. The instructions can operate on 
one hardware register or on a set of hardware registers. The series of instructions can 
populate a resource table which can include, for example, the primitive operation, the 
register's location, register's size, value, bitmask detailing the bits to read and/or write, 

25 an action indicator specifying which action the instruction is part of, etc. According to 

one aspect of the present invention, the linking component 230 can link together the 
series of instructions and store the action in firmware associated with a hardware device, 
however the present invention is not so limited. 

According to another aspect of the invention, the resource table 130 can be 

30 loaded to the operating system concurrently with an Advanced Configuration and Power 
Interface (ACPI) table. The ACPI table facilitates robust operating system directed 
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configuration and power management of devices. The ACPI table is loaded prior to 
operating system kernel availability. Therefore, the actions for unique hardware devices 
can be implemented prior to boot or during initialization. The present invention, 
however, is not so limited to require utilization of an ACPI table and/or device 

5 interaction during and/or prior to boot. 

Figure 3 illustrates a system 300 for specifying hardware functionality in 
accordance with an aspect of the present invention. A hardware 310 (e.g., 1 10) can 
comprise any register based hardware device with unique, hardware specific 
functionality. It is to be appreciated that hardware 310 can include software, firmware 

10 and hardware components. A specification component 320 (e.g., 120 and 220) is 

operatively connected to the hardware 310 which facilitates specification of hardware 
functionality. The specification component 320 can employ a pseudo-language and a 
means to link instructions, for example via the pseudo language component 220 and the 
linking component 230, respectively. 

1 5 As discussed supra, a pseudo-language component can employ a set of hardware 

register primitives. For example, the hardware register primitives can be reads, writes, 
masked reads, masked writes, etc. of the hardware registers associated with the hardware 
310. The pseudo-language component is a common platform to describe unique, 
hardware specific functionality. The pseudo-language component permits use of a 

20 common driver to implement the hardware 310 and thus, reduces the need for hardware 
specific device drivers. 

A linking component, as previously described, can join together a series of 
instructions for specifying an action or executing an action. The present invention 
contemplates that the action can be unique to one vendor's hardware device, or can be 

25 performed by a plurality of devices within the device's class. 

An artificial intelligence component 330 can be employed to infer a series of 
hardware register primitives which comprise the action. The artificial intelligence 
component can query the hardware device 310 and determine functionalities of the 
hardware 310. Also, the artificial intelligence component 330 can infer the actions 

30 which can be effectuated by the hardware 3 1 0. Additionally, the artificial intelligence 
component 330 can infer the series of instructions which comprises each of the actions. 
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Furthermore, the artificial intelligence component 330 can query the registers to 
determine primitive operation, location, size, etc. Utilizing the series of instructions, the 
artificial intelligence component 330 can populate a hardware resource table which 
includes, for example, the primitive operation, the register's location, size, value, 

5 bitmask describing the bits to read and/or write, action indicator specifying the action 
the instruction is part of, etc. 

Thus, the AI component can employ for example a probabilistic-based and/or 
statistical-based analysis in connection with decision-making in accordance with the 
subject invention. Moreover, in connection with such decision making, the AI 

10 component 330 can perform a utility-based {e.g., cost benefit) analysis such that the cost 
associated with taking an incorrect action is weighed against the benefits of taking correct 
action in connection with the subject invention. As noted supra, inference can be 
employed to identify a specific context or action, or can generate a probability 
distribution over states, for example. The inference can be probabilistic - that is, the 

1 5 computation of a probability distribution over states of interest based on a consideration 
of data and events. Inference can also refer to techniques employed for composing 
higher-level events from a set of events and/or data. Such inference results in the 
construction of new events or actions from a set of observed events and/or stored event 
data, whether or not the events are correlated in close temporal proximity, and whether 

20 the events and data come from one or several event and data sources. 

As will be readily appreciated from the subject specification, the subject invention 
can employ classifiers that are explicitly trained (e.g., via a generic training data relating 
to registers and functionalities) as well as implicitly trained (e.g., via observing user 
and/or device behavior, receiving extrinsic information. . .) so that the classified s) 

25 automatically perform actions in accordance with desired preferences. For example, with 
respect to Support Vector Machines (SVM) which are one specific type of classifier- 
based tools - it is to be appreciated that other classifier models can also be utilized such 
as Naive Bayes, Bayes Net, decision tree and other learning models - SVM's are 
configured via a learning or training phase within a classifier constructor and feature 

30 selection module. A classifier can be a function that maps an input attribute vector, x = 
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(xl, x2, x3, x4, xn), to a confidence that the input belongs to a class - that is, f(x) = 
confidence(class). 

To illustrate an aspect of the present invention, a watchdog timer can be queried 
by the artificial intelligence component 330. The artificial intelligence component 330 
can determine actions which can be performed by the watchdog timer, such as, for 
example, resetting the timer. Utilizing the common platform described by the pseudo- 
language, the artificial intelligence component 330 can determine a series of instructions 
to effectuate the action. The linking component can then join together the instructions 
and populate the hardware resource table with the hardware register primitives and 
associated resources. 

Figure 4 illustrates an instruction set 400 that specifies a higher level action 410 
in accordance with an aspect of the present invention. The high level action 410 can be, 
for example, rebooting a computer, resetting a timer, etc. A series of instructions (e.g., 
instruction 1 (420), instruction 2 (430), instruction 3 (440), . . ., instruction N (450)), 
which operate on one or more hardware register(s) associated with the hardware device 
effectuate the hardware action 410. The instructions 420-450 comprise operations such 
as, for example, reads, writes, masked reads, masked writes, etc. of hardware register(s). 
In addition to the primitive operation, implementation of the action requires the 
instructions 420-450 to employ the register's location, size, value, bitmask describing 
bits to read and/or write, etc. Furthermore, an action indicator can be included with each 
primitive operation to identify the action with which the instruction is associated. 

The present invention contemplates a plurality of actions 410 associated with 
respective hardware device. A single software driver can execute the instruction set for 
a particular action by performing the series of instructions 420-450 associated with the 
action 410 since the instructions are described in a common manner utilizing a common 
hardware representation pseudo-language. Therefore, higher level actions 410 can be 
performed without hardware specific drivers. 

Figure 5 illustrates instruction sets 500 for facilitating a higher level action 505 
utilizing disparate hardware devices 510-515 in accordance with an aspect of the present 
invention. Device A (510) and Device B (515) can perform Action 1 (505), which can 
be, for example, rebooting a system, resetting a timer, etc. The devices 5 1 0-5 1 5 can be 
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manufactured by different vendors, can have disparate functionalities and can employ 
registers which operate differently. 

Both Device A (510) and Device B (515) can perform Action 1 (505). In the 
example, device 510 utilizes instructions 520-535, whereas device 515 utilizes 
5 instructions 540-555. The chain of instructions differ from device to device, as 

demonstrated by Device A (5 10) utilizing a series comprising Instruction 1_A (520), 
Instruction 2_A (525), Instruction 3__A (530), Instruction N_A (535) and Device B 
(515) employing a series comprising Instruction 1_B (540), Instruction 2_B (545), 
Instruction 3_B (550), Instruction MJB (555). Additionally, the number of 

10 instructions that encompass each action can vary between devices. 

Figure 6 illustrates a system 600 for specifying hardware functionality in 
accordance with an aspect of the present invention. Two hardware devices, a device 605 
and a device 610, are depicted to exemplify the present invention. However, the 
example is not limitative. For example, any number of devices can be utilized, and thus 

1 5 the invention is not so limited. The hardware devices 605-610 can be, for example, 
watchdog timers, debugger ports, EMS ports, interrupt controller, bus controller , etc. 
The hardware devices 605-610 are coupled to registers 615-620, respectively. The 
number, size, location, value, etc. of the registers 615-620 are unique to the hardware 
devices 605-610. The registers 615-620 can be physically integrated into the hardware 

20 device 605-610. Additionally, the registers 615-620 can vary in size {e.g., 16 bit, 32 bit, 
64 bit, ...). 

The hardware devices 605-610 additionally can utilize hardware resource tables 
625-630, respectively, to describe the hardware devices 605-610 to a software 
component. The hardware resource tables 625-630 include a series of instructions, 

25 which can be linked together to perform an action. More than one action can reside 
within the hardware resource table 625-630. The series of instructions comprise 
hardware register primitives that are defined by the pseudo-language, which facilitates a 
common framework to implement the present invention. According to an aspect of the 
present invention, the hardware resource tables 625-630 can be fixed resource tables 

30 defined by the Advanced Configuration and Power Interface (ACPI) Specification, 
Version 2.0. 
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The hardware resource tables 625-630 can be stored contiguously by the 
firmware vendor in memory of the hardware devices 605-610. As known, firmware is 
software which is embedded in the hardware device that can be read and modified by the 
device user, but cannot be written to or deleted. 
5 To exemplify the hardware resource tables 625-630, reference is made to a 

watchdog resource table (WDRT) for a watchdog timer. The example is made for 
illustration purposes and the invention is not so limited. The watchdog resource table 
(WDRT) can be defined as follows: 



Field 


Byte 


Byte 


Description 




Length 


Offset 




A CPI Standard Header 








Header Signature 


4 


0x0 


'WDRT'. Signature for the Watchdog 








Resource Table. 


Length 


4 


0x4 


Length, in bytes, of entire WDRT. 








Entire table must be contiguous. 


Revision 


1 


0x8 


2 


Checksum 


1 


0x9 


Entire table must sum to zero. 


OEMID 


6 


OxA 


OEMID 


OEM Table ID 


8 


0x10 


The manufacturer model ID. 


OEM Revision 


4 


0x18 


OEM revision of the WDRT for the 








supplied OEM Table ID. 


Creator ID 


4 


OxlC 


Vendor ID of the utility that created 








the table. 


Creator Revision 


4 


0x20 


Revision of the utility that created the 








table. 


Watchdog Header 








Watchdog Header Length 


4 


0x24 


Length of Watchdog Header 


PCI Segment 


1 


0x28 


PCI segment number. For systems 








which don't support PCI Segments, 








this number must be OxFF. 


PCI Bus Number 


1 


0x29 


PCI Bus Number is table describes a 








PCI device. Must be OxFF if it is not ; 








PCI device. 


PCI Device Number 


1 


0x2A 


PCI Device Number if table describes 








a PCI device. Must be OxFF if it is no 








a PCI device. 


PCI Function Number 


1 


0x2B 


PCI Function Number if table 
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Timer Period 



Max Count 



Min Count 



Watchdog Flags 



Reserved 

Number Watchdog 
Instruction Entries 

Watchdog Action Table 

Watchdog Instruction 
Entries 



3 
4 



0x2C 



0x30 



0x34 



0x38 



0x39 
0x3C 



0x40 



describes a PCI device. Must be OxFF 
if it is not a PCI device. 
Contains the period of one timer count 
(in milliseconds). 

Contains the maximum counter value 
that this watchdog implementation 
supports (in count intervals). 
Contains the minimum counter value 
that this watchdog implementation 
supports (in count intervals). 
Each flag that is true for the watchdog 
hardware should have the appropriate 
flag set in Watchdog Flags. All other 
bits should be zero. 

Contains the number of Watchdog 
Instruction Entries in the table. 



A series of Watchdog Instruction 
Entries. 



The watchdog resource table comprises three sections, namely the ACPI 
Standard Header, Watchdog Header and the Watchdog Action Table. The Watchdog 
Header describes global information regarding the watchdog hardware and the structure 
of the table. The Watchdog Action Table includes a series of instruction entries (e.g., 
primitive operation, register size, register location, value, bitmask, . . .) to interact with 
the register(s) 615-620 of the hardware device 625-630 to perform high level actions. 

The following is an exemplary watchdog instruction entry: 



Field 

Action Identifier 

Instruction Flags 
Reserved 
Register Size 



Byte 

Length 

1 

1 
1 
1 



Byte 

Offset 

N 

N+Oxl 
N+0x2 
N+0x3 



Register Region 



12 



N+0x4 



Description 

The Watchdog Action this instruction 
is part of. 

Primitive instruction 

Size of the watchdog hardware 
register utilized in this instruction. 
Size is in bytes with the max value of 
4 bytes. 

Generic Address Structure as defined 
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Value 



Mask 



N+OxlO 



N+0xl4 



in section 5.2.3. 1 of the ACPI 
Specification to describe the address 
and bit 

The value corresponding to the given 
Watchdog Instruction. 
The bit mask required to obtain the 
bit(s) corresponding to the Watchdog 
Instruction in a given bit range 
defined by Register Region. 



The instruction flag indicates a primitive action as defined by the pseudo- 
language. The pseudo-language can provide an abstraction to facilitate utilization of a 
common software driver for disparate hardware devices. For example, the primitives 
can be reads, writes, masked reads, masked writes, etc. of hardware register(s) 615-620. 
For example, the pseudo-code for read and write hardware register primitives can be 
defined as follows: 



READ: 

10 X = Read(register) 

X = X » Bit Offset described in Register Region 
X = X&Mask 



WRITE: 

15 X = Value & Mask 

X = X « Bit Offset described in Register Region 
If (Preserve Register) 

Y = Read(register) 

Y = Y & -(Mask « Bit Offset) 
20 X = X|Y 

Write(X,Register) 



The system 600 additionally comprises an Advanced Configuration and Power 
Interface (ACPI) table 635, although the device is not so limited. The ACPI 
25 specification facilitates a common interface for robust operating system directed 
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configuration and power management. The ACPI table 635 describes the interface to 
the hardware. 

The system 600 also comprises a processing component 640. The processing 
component 640 utilizes a boot loader which can concurrently load the ACPI table 635 
5 and the hardware resource tables 625-630 for each hardware device 605-610 described 
in the ACPI namespace. The ACPI namespace is part of the ACPI BIOS set up by 
hardware vendors and is a hierarchical tree structure in operating system controlled 
memory. Thus, the hardware resource tables 625-630 can be loaded prior to boot or 
during initialization. 

1 0 Once the hardware resource tables 625-630 are loaded, the processing 

component 640 is operable to perform a hardware action (e.g., reboot system, reset 
timer, ..,). The processing component 640 achieves the hardware action by effectuating 
a series of instructions which are stored in the hardware resource tables 625-630. The 
instructions comprises hardware register primitives which are defined according to a 

15 common hardware register pseudo-language. The primitives are operations such as, for 
example, reads, writes, masked reads, masked writes, etc. of one or more registers 
associated with a unique hardware device. Additionally, the processing component 640 
utilizes resources (e.g., register's location, size, value, bitmask detailing bits to read 
and/or write, action identifier, . . .) stored in the hardware resource tables 625-630 to 

20 perform the higher level actions. The series of instructions are linked together to 
effectuate the high level action. The high level action can be performed prior to 
operating system kernel availability since the hardware resource tables 625-630 are 
loaded with the ACPI table 635. 

Figure 7 illustrates a system 700 for specifying hardware functionality according 

25 to an aspect of the present invention. The system comprises a hardware device 705 and 
a hardware device 710 which can be, for example, watchdog timers, debugger ports, 
EMS ports, interrupt controller, bus controller, etc. Although two hardware devices are 
represented, the present invention is not so limited. 

The hardware devices 705-710 are operably connected to registers 715-720 that 

30 are unique dependent upon hardware vendor design. For example, disparate sizes, 

locations, numbers of registers, etc. are utilized to facilitate unique device functionality. 
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Functionality of the hardware devices 705-710 is effectuated by reading from and 
writing to the hardware registers 7 1 5-720. 

The system 700 further comprises a processing component 725. The processing 
component 725 interacts with the hardware devices 705-710 to utilize the functionalities. 

5 The processing component 725 comprises an artificial intelligence component 730 
which infers characteristics of the hardware device 705-710 and/or the registers 715- 
720. The artificial intelligence component 730 can infer the unique actions which the 
hardware devices 705-710 are capable of performing. Additionally, the artificial 
intelligence component 730 can assemble instructions including hardware register 

10 primitives, which are operations such as, for example, reads, writes, masked reads, 
masked writes, etc. of hardware registers 715-720, into a series to perform the higher 
level actions. The hardware register primitives are specified according to a common 
hardware register pseudo-language. 

Once the artificial intelligence component 730 links the series of instructions, the 

15 processing component 725 can control functionality of the hardware devices 705-710. 

The processing component utilizes the series of instructions, which comprising hardware 
register primitives and additional resources such as, for example, register's size, 
location, value, bitmask, etc. to effectuate hardware device functionality. 

Figures 8-10 illustrate methodologies in accordance with the present invention. 

20 For simplicity of explanation, the methodologies are depicted and described as a series 
of acts. It is to be understood and appreciated that the present invention is not limited by 
the acts illustrated and/or by the order of acts, for example acts can occur in various 
orders and/or concurrently, and with other acts not presented and described herein. 
Furthermore, not all illustrated acts may be required to implement a methodology in 

25 accordance with the present invention. In addition, those skilled in the art will 

understand and appreciate that a methodology could alternatively be represented as a 
series of interrelated states {e.g., state diagram) or events. 

Turning to Figure 8, a methodology 800 for specifying hardware functionality 
starts the system at 810. This can include, for example, booting a computer, etc. At 820, 

30 a hardware resource table is loaded. The hardware resource table can be created by BIOS 
and/or firmware and stored in memory. An operating system's boot loader loads the 
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hardware resource table. According to an aspect of the present invention, the hardware 
resource table can be an Advanced Configuration and Power Interface (ACPI) table. The 
hardware resource table is available in the ACPI namespace. The ACPI namespace is a 
hierarchical tree structure in operating system controlled memory that contains named 
5 objects. The boot loader initializes, starts and pings the hardware device; thus, the 
hardware resource table can be loaded prior to boot or during initialization and the 
hardware device can be accessible prior to operating system kernel availability. The 
device can be accessible prior to kernel initialization by requiring the device description 
to available prior to the kernel, which can be accomplished, for example, utilizing an 

1 0 ACPI table. The hardware resource table comprises a series of instructions which are 
linked together to perform a higher level action upon the hardware device. 

At 830, a high level action is performed. The high level action comprises a series 
of instructions which comprise hardware register primitives defined by a common 
hardware register pseudo-language. The high level action can be, for example, rebooting 

1 5 a system, resetting a timer, etc. The present invention contemplates performing more 
than one action as shown by decision block 840. 

Figure 9 illustrates a flow diagram for another methodology 900 for carrying out 
the present invention. At 910, a system is started. This can include, for example, booting 
a computer, etc. which begins operation of the boot loader. At 920, the hardware 

20 resource table is loaded by the boot loader. The hardware resource table can be a fixed 
resource table defined according to the ACPI Specification, Version 2.0, for example. 
The hardware resource table can be created by firmware and stored in memory associated 
with the hardware device and contains a series of hardware register primitives unique to 
the hardware device which define hardware actions. Since the boot loader loads the 

25 hardware resource table, the hardware device can be accessible prior to operating system 
kernel availability. 

At 930 - 950 a series instructions comprising hardware register primitives (1 
though N, wherein "N" is an integer) are performed. The hardware register primitives 
can be, for example, reads, writes, masked reads, masked writes, etc. of at least one 
30 hardware register associated with a hardware device. The series of instructions are 
unique to the vendor's hardware device and the linked series of instructions describes 
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higher level actions utilizing abstractions to allow a single software component to be 
utilized for disparate hardware designs. The number of instructions is hardware specific. 
The primitives are defined according to a common framework by utilizing a common 
hardware register pseudo-language. At 960, it is determined whether or not all relevant 
5 instructions for the particular functionality are executed, this process continues until all 

instructions required to effect the functionality are loaded. Once, complete, the process 
determines at 970 if another functionality is desired to be effected, and if so, instructions 
associated therewith are executed until complete. 

Figure 10 illustrates a methodology 1000 for specifying hardware functionality 

10 according to an aspect of the present invention. A system is started at 1010. For 

example, a computer can be booted, etc. At 1020, artificial intelligence infers actions 
which a unique hardware device can perform. For example, the artificial intelligence can 
determine that a hardware device such as a watchdog timer is operable to perform a reset 
of the timer. The artificial intelligence can also infer a series of instructions which can 

1 5 effectuate the hardware action. Instructions comprise hardware register primitives and 

resources to perform the primitive (e.g., register's location, register's size, value, bitmask 
detailing the bits to read and/or write. The hardware register primitives are defined 
according to a common register pseudo-language. 

At 1030, the series of instructions determined at 1020 are effectuated. The series 

20 of instructions is defined by the unique hardware device. The primitives utilized can be, 
for example, reading, writing, masked reading, masked writing, etc. of hardware 
register(s) to effectuate a high level action. At 1040, it is determined whether or not all 
relevant instructions for the particular functionality are executed; this process continues 
until all instructions required to effect the functionality are executed. Once, complete, the 

25 artificial intelligence infers at 1050 if another functionality is desired to be effected, and 
if so, instructions associated therewith are executed until complete. 

Figure 1 1 illustrates one possible hardware configuration to support the systems 
and methods described herein. It is to be appreciated that although a standalone 
architecture is illustrated, that any suitable computing environment can be employed in 

30 accordance with the present invention. For example, computing architectures including, 
but not limited to, stand alone, multiprocessor, distributed, client/server, minicomputer, 
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mainframe, supercomputer, digital and analog can be employed in accordance with the 
present invention. 

With reference to Figure 1 1, an exemplary environment 1 1 10 for implementing 
various aspects of the invention includes a computer 1112, including a processing unit 
5 1 1 14, a system memory 1116, and a system bus 1 1 1 8 that couples various system 

components including the system memory to the processing unit 1114. The processing 
unit 1114 may be any of various commercially available processors. Dual 
microprocessors and other multi-processor architectures also can be used as the 
processing unit 1114. 

10 The system bus 1118 may be any of several types of bus structure including a 

memory bus or memory controller, a peripheral bus, and a local bus using any of a 
variety of commercially available bus architectures. The computer memory 1116 
includes read only memory (ROM) 1 120 and random access memory (RAM) 1 122. A 
basic input/output system (BIOS), containing the basic routines that help to transfer 

15 information between elements within the computer 1112, such as during start-up, is 
stored in ROM 1120. 

The computer 1112 may further include a hard disk drive 1 124, a magnetic disk 
drive 1 126, e.g., to read from or write to a removable disk 1 128, and an optical disk drive 
1 130, e.g., for reading a CD-ROM disk 1 132 or to read from or write to other optical 

20 media. The hard disk drive 1 124, magnetic disk drive 1 126, and optical disk drive 1 130 
are connected to the system bus 1 1 18 by a hard disk drive interface 1 134, a magnetic disk 
drive interface 1 136, and an optical drive interface 1 138, respectively. The computer 
1112 typically includes at least some form of computer readable media. Computer 
readable media can be any available media that can be accessed by the computer 1112. 

25 By way of example, and not limitation, computer readable media may comprise computer 
storage media and communication media. Computer storage media includes volatile and 
nonvolatile, removable and non-removable media implemented in any method or 
technology for storage of information such as computer readable instructions, data 
structures, program modules or other data. Computer storage media includes, but is not 

30 limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD- 
ROM, digital versatile disks (DVD) or other magnetic storage devices, or any other 
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medium which can be used to store the desired information and which can be accessed by 
the computer 1112. Communication media typically embodies computer readable 
instructions, data structures, program modules or other data in a modulated data signal 
such as a carrier wave or other transport mechanism and includes any information 
5 delivery media. The term "modulated data signal" means a signal that has one or more of 

its characteristics set or changed in such a manner as to encode information in the signal. 
By way of example, and not limitation, communication media includes wired media such 
as a wired network or direct-wired connection, and wireless media such as acoustic, RF, 
infrared and other wireless media. Combinations of any of the above should also be 

1 0 included within the scope of computer readable media. 

A number of program modules may be stored in the drives and RAM 1 122, 
including an operating system 1 140, one or more application programs 1 142, other 
program modules 1 144, and program non-interrupt data 1 146. The operating system 
1 140 in the computer 1112 can be any of a number of commercially available operating 

15 systems. 

A user may enter commands and information into the computer 1112 through a 
keyboard 1 148 and a pointing device, such as a mouse 1 150. Other input devices (not 
shown) may include a microphone, an IR remote control, a joystick, a game pad, a 
satellite dish, a scanner, or the like. These and other input devices are often connected to 

20 the processing unit 1114 through a legacy device interface 1 1 52 that is coupled to the 

system bus 1118, but may be connected by other interfaces, such as a parallel port, serial 
port, a game port, a universal serial bus ("USB"), an IR interface, etc. A monitor 1 154, 
or other type of display device, is also connected to the system bus 1118 via an interface, 
such as a video adapter 1 156. In addition to the monitor, a computer typically includes 

25 other peripheral output devices (not shown), such as speakers, printers etc. 

The computer 1112 may operate in a networked environment using logical and/or 
physical connections to one or more remote computers, such as a remote computer(s) 
1 158. The remote computer(s) 1158 may be a workstation, a server computer, a router, a 
personal computer, microprocessor based entertainment appliance, a peer device or other 

30 common network node, and typically includes many or all of the elements described 

relative to the computer 1112, although, for purposes of brevity, only a memory storage 
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device 1 160 is illustrated. The logical connections depicted include a local area network 
(LAN) 1 162 and a wide area network (WAN) 1 164. Such networking environments are 
commonplace in offices, enterprise-wide computer networks, intranets and the Internet. 
When used in a LAN networking environment, the computer 1 1 12 is connected to 

5 the local network 1 1 62 through a network interface or adapter 1 1 66. When used in a 

WAN networking environment, the computer 1112 typically includes a modem 1 168, or 
is connected to a communications server on the LAN, or has other means for establishing 
communications over the WAN 1 164, such as the Internet. The modem 1 168, which may 
be internal or external, is connected to the system bus 1 1 18 via a serial port 1 167 and the 

10 legacy device interface 1 152. In a networked environment, program modules depicted 
relative to the computer 1 1 12, or portions thereof, may be stored in the remote memory 
storage device 1 160. It will be appreciated that the network connections shown are 
exemplary and other means of establishing a communications link between the computers 
may be used. 

15 Figure 12 is a schematic block diagram of a sample-computing environment 1200 

with which the present invention can interact. The system 1200 includes one or more 
client(s) 1210. The client(s) 1210 can be hardware and/or software {e.g., threads, 
processes, computing devices). The system 1200 also includes one or more server(s) 
1230. The server(s) 1230 can also be hardware and/or software {e.g., threads, processes, 

20 computing devices). The servers 1230 can house threads to perform transformations by 
employing the present invention, for example. One possible communication between a 
client 1210 and a server 1230 may be in the form of a data packet adapted to be 
transmitted between two or more computer processes. The system 1200 includes a 
communication framework 1250 that can be employed to facilitate communications 

25 between the client(s) 1210 and the server(s) 1230. The client(s) 1210 are operably 
connected to one or more client data store(s) 1260 that can be employed to store 
information local to the client(s) 1210. Similarly, the server(s) 1230 are operably 
connected to one or more server data store(s) 1240 that can be employed to store 
information local to the servers 1230. 

30 What has been described above includes examples of the present invention. It is, 

of course, not possible to describe every conceivable combination of components or 
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methodologies for purposes of describing the present invention, but one of ordinary skill 
in the art may recognize that many further combinations and permutations of the present 
invention are possible. Accordingly, the present invention is intended to embrace all 
such alterations, modifications and variations that fall within the spirit and scope of the 
appended claims. Furthermore, to the extent that the term "includes" is used in either the 
detailed description or the claims, such term is intended to be inclusive in a manner 
similar to the term "comprising" as "comprising" is interpreted when employed as a 
transitional word in a claim. 
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